Description

Fix collision prospect checking to be fully reliable.

Turns out there is still a high-percent chance of hash collisions even with #3864 on our tests, causing CI flakyness.

This completely bypasses the issue by making the code collision-resistent to begin with. This is orthogonal to improving hashing collision rate.

At first I added my own implementation of Set but then realize that we can just use Dart's set, if we are clever about it. It already handles collisions elegantly (i.e. with no performance penalty if there are no collisions), by using a flat array with index fallbacks. Every recover check pays one hash and at least one identity check which are very cheap.

We just need to implement hashCode and equals, the hash can use the existing approximation, and the equals can use the unordered identity check.

This bulks up the pool implementation to hide the "mutable" view over CollisionProspect, which I made a immutable first-class citizen. No one can mutate the prospect other than the pool, that owns the lifecycle.

At the end of the day there was no reason for these sets to be a map keyed on hashcode. That is just a poor-mans set!

I dare say it is impossible for the CI to flake now :P

Checklist

• I have followed the Contributor Guide when preparing my PR.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• I have updated/added relevant examples in examples or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.